1. Technical Field
The present invention generally relates to vehicle diagnostic tools.
2. Background Information
In the past, diagnostic tools used in car dealerships were bespoke, handheld tools with self-contained software and proprietary hardware. These tools were first offered in the late 1980's when vehicles began to incorporate fuel injection and onboard computer systems. They would allow the technician to read data from the onboard computer systems on their self-contained screen and use a keypad to perform diagnostic tests on the engine computer.
Starting around the year 2000, these diagnostic systems began shifting from bespoke handheld systems to PC-based applications that would connect to the vehicle using a pass-thru interface. This shift was necessary because the complexity of the user interface and amount of vehicle diagnostic data was exceeding the limitations of the bespoke handheld systems.
As these PC systems grow to support more advanced vehicles, they are becoming increasingly complex and difficult for car companies to manage and develop. The typical diagnostic system is comprised of an end user application with proprietary information incorporated inside, database of vehicle-specific diagnostic information, authoring tools to add support for new vehicles, and database that records diagnostic transactions for every vehicle. In some cases the end user application and database with diagnostic information are compiled into a single executable and in other cases the database with diagnostic information is located on a server on the internet.
A single vendor is typically hired to develop the entire diagnostic system because no one has ever developed a way separate out the components of the system into pieces. The single-vendor nature of the business has created several issues for car companies and end users. The diagnostic system is limited to the resources and technical capabilities of that vendor. If the car company wants a feature, it must pay whatever price that vendor demands because the car company cannot ask another vendor to create features inside the closed system. If the car company is not happy with the relationship and wishes to terminate with that vendor, they have to discard the entire diagnostic system and start fresh with a new vendor in a process that typically takes more than a year.
While the original diagnostic system is used at car dealerships and in some aftermarket shops, there is also a large market for third party diagnostic systems. These systems, made by companies such as Snap-on, Launch, and Bosch, offer technicians the capability to diagnose vehicles from several car companies instead of the dealer system that can only diagnose one make. Many technicians use these third party systems because they are simple to use and share the same user interface across multiple brands of vehicles. The information in these third party systems is often licensed from the car company or reverse engineering if otherwise not available.
When a third party company licenses diagnostic information from a car company, the information is typically provided to the third party company as a set of files or databases that represent all of the diagnostic information at that one moment in time. The third party companies then have to aggregate all of the diagnostic information from several different car companies into a single system, test that application, and release it to the aftermarket.
The problem with third party diagnostic systems is that they do not always have complete and correct diagnostic information for vehicles. This is because the third party systems license the data from car companies but often get out of date or incorrect information. There is no way for third party companies to access the authored data already in the diagnostic system in real time so they must purchase a database or series of files that contain the diagnostic information for each year/make/model of car and then input that into the third party system. There can be transcription errors, and often times the car company will update their own diagnostic information but those updates do not make it into the third party system. It can also take many months for third party systems to get access to this information, author it into their own system, test it, and release it. Some problems with the current system that solved by the present invention include:
1. The current model forces the car company to use a single vendor for all aspects of their diagnostic system. If the vendor is not expert in all areas, the car company may be forced to compromise on features, cost, or performance.
2. If the car company is unhappy with the vendor's performance and wants to switch or develop things in-house, they often have to throw away the entire system and create a new system.
3. If the car company wants to expand their system to different platforms (such as mobile phones or tablets), they must pay their existing vendor to expand the system and new versions. Sometimes vendors may be unwilling or unable to expand their system to new platforms.
4. The way car companies license their diagnostic information to third parties is inefficient, expensive to maintain, and prone to introducing errors into third party applications.
5. In the current model, car companies are forced to license their diagnostic data that contains secret algorithms and other intellectual property to scantool companies with no built-in protection for that IP.